We love open-source software. In context of our mission #moresecurity, Christian Pöschl, security consultant and penetration tester at usd HeroLab had a look at Foswiki as a research project. In this blog post, we summarize the journey to discover the functionality of Foswiki and identify multiple vulnerabilities, which ultimately allowed us to elevate privileges from a freshly registered user to full remote code execution on the server. All vulnerabilities were reported to the developers according to our Responsible Disclosure Policy. Thanks to the prompt reaction of the Foswiki development team, the attack described below is no longer possible in TopicInteractionPlugin version 9.20.
Introdction
Foswiki is a widely used wiki application allowing users to collaborate and exchange knowledge on different topics. This kind of software is often used in companies to provide a document management system or knowledge base. Foswiki allows its users to define access-controls, make use of revisioning and search for pages. Foswiki is open source and written in Perl programming language. Unlike other wiki applications, content is not stored in a database but on the file system in simple plain text.
The software project was started in 2008 and is still actively developed. During our research we stumbled upon the following page (https://foswiki.org/About/ReasonsToUseFoswiki) which gave us reasons why everybody should use this software.
1. It's free. Totally free. No evil empire lurking in the background. Foswiki is now one out of few—if not the only—free-and-open-source-wiki for enterprises that has an official association (background) to back it.
2. It's fun. You can do amazing stuff really easily.
3. It's got a really strong community of developers, users, and professional consultants.
4. It's been used in major companies for years; it's got a great track record. See companies using Foswiki and public sites using Foswiki.
5. It's got excellent security - both access controls and protection against hackers.
Reason number 5 caught our eye and we decided to test whether the security and access controls were as secure as advertised.
During our research we discovered multiple bugs and intended features in a common Foswiki plugin and Foswiki Core. Chaining these together enabled a registered user to execute arbitrary commands on the underlying system.
Technical Details
This section describes how we discovered the vulnerability. It can also be seen as a writeup to exploit the vulnerabilities of Foswiki version <=2.1.7 with enabled TopicInteractionPlugin up to version 9.20 to execute arbitrary system commands. This plugin is also maintained by the Foswiki Team and one of the most common plugins of Foswiki.
Starting Point
We deployed an up-to-date version of Foswiki for our research via a Docker Image. The image comes with multiple common plugins pre-installed. Such an environment allows us to perform tests and view the source code of the application, while also debugging at runtime.
A major goal of the software is the collaboration between different users. Therefore, Foswiki supports LDAP and user registration. For the following blog post we assume that you already have an account in the application and can log in.
The following screenshot shows the user details for our fresh user "Chris Chris". Since we just signed up for the application, our user has almost no permissions.
As already mentioned above, the content of each page is stored on the server in a simple text file. In addition, we discovered that these files also define the access permissions. To illustrate this, let's have a deeper look at the /Main/AdminGroup page. It shows information on how to login and reset the password for administrators. The page looks like a typical Foswiki page. However, this page contains more functionalities that unprivileged users are not able to see (yet).
According to the documentation (https://foswiki.org/System/AccessControl), members of the AdminGroup are allowed to access the Foswiki configuration page (/bin/configure). Foswiki allows users to viewthe pages in a raw format. The following path of the URL can be visited to access the raw page content: /Main/AdminGroup?raw=all;skin=text. Except for the content, the raw page also contains macros. The following screenshot shows the raw file for this page:
Macros in Foswiki always use the same format %META:<type>{key1="value" key2="value2" ...}%. These macros can be used to include information such as file attachments, topic movement history, and form field values. The macro type PREFERENCE is particularly interesting because it can be used to define access controls.
Foswiki writes that you can create new administrators simply by adding them to the AdminGroup topic. Members of the AdminGroup have unrestricted access to all parts of the wiki, so only trusted staff should be added to this group. The macro in the raw content is marked in the screenshot. The line indicates that only members of the AdminGroup can add members to the /Main/AdminGroup page, which is shown in the ALLOWTOPICCHANGE preference at the bottom of the page. This will come in handy later.
Bring your own Wiki Page
Users can create new wiki pages in the sandbox mode which is available at /Sandbox. For further instructions we need to disable the WYSIWYG editor in the "Settings" tab. This prevents formatting issues when submitting new pages. We can paste in the same data as the raw output of /Main/AdminGroup. The visible content remains the same but the macro for ALLOWTOPICCHANGE in line 18 differs. Note that we added our user (ChrisChris) to the list of users and groups there.
%META:TOPICINFO{author="BaseUserMapping_999" comment="" date="1648462765" format="1.1" version="1"}%
%META:TOPICPARENT{name="WikiGroups"}%
%INCLUDE{"%USERSWEB%.AdminUser" section="sudo_login"}%
%IF{"(NOT defined GROUP) OR $GROUP = ''" then='
*How to add the first administrator* %BR%
If you haven\'t previously set up an administrator, follow these steps: (*Note:* This help text will disappear once you have added a user to this group.)
$percntINCLUDE{"%SYSTEMWEB%.InstallationGuide" section="addadmin"}$percnt
'}%
More information on Administrators, and on how to use the AdminGroup is found in the [[%SYSTEMWEB%.InstallationGuide#DefineAdminUser][Installation Guide]]
You can edit this topic to add a description to the AdminGroup
%META:PREFERENCE{name="GROUP" title="GROUP" type="Set" value=""}%
%META:PREFERENCE{name="ALLOWTOPICCHANGE" title="ALLOWTOPICCHANGE" type="Set" value="AdminGroup,ChrisChris"}%
%META:PREFERENCE{name="VIEW_TEMPLATE" title="VIEW_TEMPLATE" type="Set" value="GroupView"}%Creating such a page does not add the user ChrisChris as a member to the AdminGroup since the created page is not stored in /Main/AdminGroup. However, an overwrite of this page with the one shown above would result in elevated privileges for user ChrisChris. Foswiki provides a feature to move pages to different directories. Our initial idea was to overwrite the original /Main/AdminGroup with our custom one, by clicking "More" -> "Move or Rename" and specify the page we want to overwrite. The screenshot below shows how the rename and move form would look like.
Trying to overwrite the /Main/AdminGroup page results in an error. Foswiki prohibits renaming if there is already a file with the same name in the directory, as can be seen in the following screenshot:
Let’s move (Path Traversal)
Foswiki is a feature-rich application. After having a look at more features, we discovered that Foswiki allows uploading attachments and moving these attachments to other locations. Such a feature is always of particular interest for us. In our own profile page, we can add an attachment by clicking on "More" -> "Upload Files". After a successful file upload of a sample file called digits.txt, we are presented with the option to move the attachment. The next screenshot shows the attachment and an icon with arrows to move the attachment to another directory.
Moving a file results in an HTTP request like the one in the next screenshot. Intercepting this request shows an interesting filename parameter. This parameter is used to specify the relative path of the file that should be moved.
Foswiki stores the AdminGroup page in the /data/Main/AdminGroup.txt file. Uploaded attachments are stored by default in the /pub/ directory. In the Docker image we used during the tests, the installation web root was at /var/lib/foswiki/.
Our idea was: Let’s move the AdminGroup.txt file into another directory. Afterwards, we might put a malicious AdminGroup.txt file into the original location.
To move the original AdminGroup file to another location the request below can be sent.
POST /bin/rest/TopicInteractionPlugin/move HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 129
Connection: close
Referer: http://localhost/Main/ChrisChris
Cookie: FOSWIKISID=582be25dd6c36a6d45e6a37277378374; FOSWIKISTRIKEONE=21d8825b6b492836f1235aa0293bc310
validation_key=06f78c2c2612a63bf8a8eef6aee71544&id=move&filename=../../../data/Main/AdminGroup.txt&topic=Main.ChrisChris&newweb=Sandbox&newtopic=TestUsing already existing access to the file structure of the web server, we can see that the file is no longer available after the request. The following screenshot shows a command line of the system hosting Foswiki. The first ls command was executed before submitting the request. The file AdminGroup.txt is stored in the directory /data/Main/. After submitting the request, the AdminGroup.txt is moved to a different directory and is not available anymore.
Overwrite AdminGroup
So, we were able to move the original AdminGroup page to another destination. This gives us the opportunity to move our custom page to /Main/AdminGroup. All we have to do is follow the steps described above. Visit Sandbox/Test page, which contains our custom AdminGroup content and try moving the file to Main/AdminGroup again. But this time there will be no error message. The following screenshot shows the new Main/AdminGroup page.
Most of the visible content remains the same. But remember the additional macro we inserted? Our user now has the permissions to edit this topic, and therefore to alter the AdminGroup. The form at the bottom of the screenshot can be used to add new members. We inserted our user ChrisChris to the AdminGroup. Afterwards, a new navbar item called "Admin" is available and allows us to configure Foswiki.
Remote Command Execution as a AdminGroup user
Foswiki offers a wide range of settings. We came across a set of mail settings that piqued our interest because they allowed us to define the mailing binary. This binary is executed every time a mail is sent. First, the mailing functions must be activated if not already enabled.
Additional mail settings will appear afterwards, allowing us to edit the "Mail Method" to "Mail Program". This in turn will add a new "Mail Program" form to the page. Arbitrary system commands can be inserted into this form. The screenshot below shows the edited mail settings. An HTTP request to a Burp Collaborator server with the command line tool wget should be performed for every mail sent.
In the "Basic settings" tab it is possible to send a test mail. Using the previously modified settings, this results in the execution of the specified command.
The Burp Collaborator receives the request as the following screenshot proves. The request was performed as we expected with wget as the User-Agent.
Conclusion
The vulnerabilities in this blogpost were fixed in TopicInteractionPlugin version 9.20. The command execution in the last section was not remedied because the maintainer intended this feature, and the risk is accepted. We would like to thank Foswiki for their support and quick fix of the reported vulnerabilities. The security vulnerabilities in this blog post were identified by Christian Pöschl of usd AG.
In addition, multiple stored XSS vulnerabilities were also identified. These XSS vulnerabilities were also reported to Foswiki but not remedied because the maintainers marked these as an intended feature. The security advisory for this vulnerability and many more can be found at: https://herolab.usd.de/security-advisories/